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Operating System/360 Principles 


Two principles are basic to understanding Operating System/360 (0S/360). 
The first is that of a queue. The important function to be accomplished is 
resource allocation. Inactive resources waste time and, thus, cost money. In 
order to improve the efficiency (throughput) of the system, maximum use of 
limited resources may be accomplished through use of the queue. The queue is a 
way of requesting a resource so that my request is filled at the earliest possible 
moment. A familiar example of the queue is a waiting line at a ticket booth. The 
resource to be allocated is the ticket seller's time and, one by one, those who 
wait get the resource. 


The second principle is that of events. A dynamic system must manage 
multiple requests for resources. When resources later become available some way 
to grant unrelated requests must be accomplished. The event is a way to accom- 
plish this wait. We have events occurring daily. "Has the mail come yet?" is a 
question about an event which must occur before we can pay the bills or read over 
our favorite magazine. 


Waiting must be implemented in a complex system using multiprogramming. 
Two ways to accomplish this are queueing and eventing. This paper discusses how 
both apply to 0S/360. 


1. INTRODUCTION 


The advent of very powerful hardware computing systems has placed a new 
emphasis of the Programming Systems —~ the limitations have become less hardware 
oriented. Rather, performance of a system, as measured by throughput, has become 
dependent upon the software monitor which coordinates activities. It has become 
apparent that it is necessary to use a multiprogramming environment in order to 
get the most out of the system. But multiprogramming places a new demand upon 
the software; that of waiting without stopping. 


"Waiting without stopping" means that Program-l can be put into a software 
wait state while the CPU switches to Program-2 which is ready to execute. To 
determine the magnitude of the problem, consider the event that placed Program-1 
in the software wait state. Program-1 had control first for some good reason and 
should assume control again. How can this be done? (Event means only that "some- 
thing happens." This something could be an I/O interrupt or a normal program 
termination.) Multiprogrammed systems must have a way of waiting on resources 
which are not available and a way of responding to events (things that happen). 
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The two principles basic to multiprogramming are also basic to 0S/360. 
These principles are Queues and Events. 


2. WHAT IS A QUEUE? 


The queue is a method whereby one resource may be requested and/or used. 
When the resource becomes available, the queue can be used to decide what request 
should be satisfied next. 


A familiar queue is a waiting line at a ticket booth. The line of people 
waiting is itself the queue: the ticket booth is the resource. 


There are three types of resources: 


1. Immediately usable (re-entrant) 
2. One-time usable (self modifying/destroying) 
3. Serially reusable (self-initializing) 


For the approach to be consistent and flexible, it will be convenient to 
create a piece of control information which can "represent" or "stand for" the 
resource to be queued upon. In 0S/360, this control information is called a 
Queue Control Block (QCB). The QCB is one full word of core. Bit 0 of the QCB 
is a one when the resource it represents is being used (i.e., Bit 0 is the busy 
Dit); 


The type of the resource affects how many QCB's are required, Only one QCB 
is required for a re-entrant resource because any request can immediately be 
satisfied. However, a non-reusable resource requires 2 “new copy" of the resource 
for every request. For example, when a rocket is fired, the rocket is destroyed. 
If we require two rockets to meet in space, then we need two resources even though 
they might be identical twins. Every request for a non-reusable resource will thus 
require a new, additional QCB. 


Finally, the serially-reusable resource brings us back to the ticket booth. 
This is a resource upon which we can really queve and only one QCB is necessary 
for any number of requests. 


2.1 HOW ARE REQUESTS MADE? 


A queue requires not only a resource (Fig. 1) which can be allocated, but 
also requests for the resource. The basic function of a request is to specify 
what resource is being requested. This function can be implemented using a full 
word in core to address the resource being requested. The physical implementation 
of a request is called a Simple Queue Element (QEL) i.e., a part of a queue. 

(Fig. 2) 


QEL's can be located in core in two different ways: (1) the elements can 
be fixed in number and in consecutive core locations in a contiguous set of QEL's 
(Fig. 3); or (2) variable in number and distributed in core in « dtstrtbuted set 
of QEL's (Fig. 4 and 5). 
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address of 


Busy Bit 


element 


<_———_———— Full Word» 


Figure 1. Queue Control Block (QCB) 


Link Address 
(address of next) 


Figure 2. Simple Queue Element (QEL) 


QCB #1 


- "ACTIVE" 
QUEUE 
ELEMENT 


NEXT 
QUEUE 
ELEMENT 


LAST 
QUEUE 
ELEMENT 


ZERO 
(X'000000'! ) 


Figure 3. Contiguous Queue 


Request #1 — Points To 


Figure 4. Chain of Requests 
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address of next 
link in the chain 


of next 
the chain 


address of next 
link in the chain 


address of next 


link in the chain 


Figure 5. Forward Chaining 
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In addition to the forward (Fig. 5) chain of the QEL's mentioned, one can 
implement requests so that a search can be made in either direction. To imple- 
ment this, a second word is required to address the request "behind" each request. 
This QEL is now called an Expanded QEL. (Fig.6 and 7) 


2.3 HOW IS QUEUE BUILT? SERVICED? 


It is important to note the difference between the way the queue is built 
and the way that requests are granted (Fig. 8). The way that a queue is built 
refers to how addresses are placed into the QEL's. There are three common rules 
used to order a queue: a. LIFO (last in, first out) — the latest request is 
placed ahead of all other requests. This is like "cutting in" at the head of the 
ticket line, b. FIFO (first in, first out) — the latest requested is placed behind 
all other requests. This is the normal way of adding to the ticket line, c. PRIO 
(priority) — the order of requests is according to some numeric priority regard- 
less of chronological order. There is a parallel between this method and the mayor 
walking into a movie while the rest of us wait at the ticket booth. 


The manner in which requests are satisfied in a queue depends upon the 
resource. The QCB will contain, in bytes 2, 3, and 4, the address of the request 
being satisfied (or the request which presently has the resource). 


When the present request is finished with the resource, the address of the 
next request in the queue is obtained from the then-finshed QEL and the chained 


QEL is made active. From this viewpoint, the queue is being serviced in a 
manner. Simple QEL's will always be serviced on a first in, first out basis. 


Expanded QEL's may use the second word to allow requests to be serviced 
LIFO. Using this strategy, word Number 2 of the QEL is used to service the queue 
and word Number 1. is used to build the queue. 

For example: 


EQEL #1 


Address of 


EQEL #2 


EQEL #2 
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QCB #1 


Link Address Back-chain Address 
(address of next) (address of previous) 


queue element queue element 


Bit 0 = Last QEL Bit 


if = 0, then more ZERO "ACTIVE" 
qel's in queue (X'000000' ) QUEUE 
ELEMENT 


if = 1, the this gel 
is last in queue 


<q—_————-Link Address—————_»> 


Figure 6. Expanded Queue Element (EQEL) 


Figure 8. One-Request Queue 


x'80! EQEL #1 QCB #1 
QEL #1 address of 
QEL #2 
EQEL #1 


ZERO QEL #2 ZERO 


(x'000000! ) 


«@— Link Address >| <q—— Back-chain——_ > 


Address 
Figure 9. Basic Queue 


Figure 7. Backward Chaining 


QEL #1 address of 
QEL #2 


QEL #2 address of 
bis QEL #3 


QEL #3 ZERO 


Figure 10. Basic Queue With Added Request 
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When another request is made, add it on in a FIFO manner. — 
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EQEL #1 


Address of 
EQEL #2 


Address 
EQEL #3 


Address of 
QCB #1 


EQEL #3 


Address. of 
EQEL #2 


Address ; Address. of 
EQEL #3 EQEL #1 
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2.4 ADVANTAGES 


Contiguous QEL's are less flexible than distributed QEL's and require that. 
core be permanently allocated. The major reason for using contiguous QEL's is 
that it is time consuming to allocate and de-allocate core. For input/output 
operations, the time demands are very heavy (literally thousands of records per 
minutes) and thus contiguous QEL's are used. For queues that are less demanding, 
distributed QEL's allow more freedom to accomplish new approaches (Fig. 11). 


2.5 <A NOTE ON USE 


The QEL's and QCB's discussed in the preceding section. are directly involved 


in the queueing function. In order to really "do something", additional informa- 
tion is required (Fig. 12). The convenient method seems to be to add additional 
storage to the control block. 


The total of the information in the control block can now be made useful by 
way of a control program. The next topics describe how queueing is accomplished 
under 0S/360 for the following queueing control blocks: 


TASK CONTROL BLOCK - TCB 
CPU QUEUE 


REQUEST BLOCK - RB 
TASK QUEUE 
PROGRAM QUEUE 


3. PROGRAM MANAGEMENT 


Requests for load modules are numerous in any computing system. In an 
environment where many assignments can be given the CPU, the multiple use of load 
modules becomes very attractive in order to conserve core. For example: in the 
FORTRAN shop, the square root routine (SQRT) is called upon. However, if ten 
FORTRAN programs are simultaneously executed, it is possible to have ten requests 


for the SQRT routine. If the routine is 100 words, we can, through multiple copies, 
find ourselves with 1000 words (10 x 100) allocated to SQRT (Fig. 13). If, however, 
requests are queued according to some rule, we can reduce the core overhead. Notice 
that this is a trade-off, because it will require CPU time to do management functions. 


Consider three queuing rules: (1) first in, first out (FIFO); (2) last in, 
first out, (LIFO); (3) priority, highest priority first (PULL). The rule itself 
will not affect our queueing technique (QCB and QEL). In a FIFO queve for SQRT: 
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(B) Expanded Queue Elements 


Figure 11. Distributed Queues 
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QCB #1/QEL #N 


address of 
active QEL or 
ZERO or link 


Additional 
"Do Something" 
Information 


Figure 12. Relation Between Queue and Resource 
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Resource 


Figure 13. Program Management Queing Control Block 
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QEL #1 
Address of 
entry point of 
SQRT 

QEL #1 Le al Address of . 
QEL #2 
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The rule which is used to order the queue does not affect our activation of 
e the top queue element. En-queing then is just placing our request (QEL) in its 
position in the QEL chain. De-queing is just changing the addresses in the QEL's 


so that the chain no longer knows my QEL exists (Fig. 14). 


A request is granted, usually, by placing the QEL address into the QCB; thus 
activating that request. We can talk about a queue describing the manner in 
which requests are granted, not the way the queue is built, e.g., even though the 


RB's are serviced LIFO, the RB queue on a task in built FIFO. 


Returning to the management of our square root route (SQRT), the QCB and a 


list are established as shown in Figure 13. 


Resource 
QCB #1 
ist Request 
(Active) 
end Request 
QEL #1 
QEL #3 


With this kind of arrangement, we can easily add or delete requests in our 
queue. Suppose a third request occurs. We must scan the queue for the last QEL 
and insert in the second word the address of QEL 3. We must then create QEL 3 


as follows: 


QCB #1 Address of 
QEL #1 


Address of 
«é entry point to 
SQRT 


QEL #1 Address of 
% QEL #2 


QEL #2 Address of 
QEL #3 


lst Request 


end Request 


3rd Request 
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address of 


QEL #1 


address of 
entry point to 


SQRT 


address of lst Request 
QEL #3 


es ae 


ZERO end Request 


Figure 14. Program Management Queing 
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Suppose that now we find that we do not need to satisfy our second request 
because the job abnormally ended. To de-enqueue, all that needs to be done is to Let's see how this might appear in core: 
look at request 2 and "chain" around it. This process is simplified since, in 
fact, expanded QEL's are used. : 


QCB to manage Load Module 
having name of 'CAT’. 


BEFORE DE-ENQUEING 


Address of QEL 2 


Address of QEL 3 Address of QEL 1 QEL 2 Request 2 Task Control Block 
at e 


Address of QCB QEL 1 Request 1 


CB to manage 


ZERO Address of QEL 2 QEL 3 Request 3 Task time 


AFTER DE~ENQUEING 


Address of QEL 3 Address of QCB QEL 1 Request 1 
Address of QEL 3 Address of QEL 1 QEL 2 Request 2 


Request Block - RB #l 


Expanded QEL referencing Load 
Module ‘CAT’ 


Expanded QEL referencing Task Time 


TCB 
address 


ZERO Address of QEL 1 QEL 3 Request 3 


Now, if we start at QEL 1, the chain ends on the second element — QEL 3. 


QEL 2 has been chained around. The advantage of this approach includes some fast- As you might imagine, it is possible for a given Load Module to request the 
executing codes. services of another. All that must be done is to create another RB containing 
% appropriate QEL's. 
Program management can thus be implemented using QEL information and QCB 
information. Under 08/360, the list of load module QCB's is called the Contents However, we know that only one load module at a time can have CPU time. We ; % 
Directory — the QEL is part of the request block (RB). The contents directory must have a rule, therefore, for building our QEL's that reference the TCB. A 
stands for the load modules. The RB consists of a double queue with two resources: good choice appears to b® FIFO. Therefore, a request by CAT for DOG would appear 
the load module via the contents directory, and task time via the TCB. as: oe 
+ 


The Task is a set of control information, the resource for which is CPU time. 
(See Section 4, Task Management ) 


Address o 


CAT entr 
ne 
address faddress 


OF 


; QEL referencing 'CAT' 
To get some useful work done by the computing system, we need at least two 
resources: Task time (TCB), and a program (Load Module-Contents Directory). The 


queue elements, which request these resources, are in the RB. QEL referencing CPU time 


RB #2 
— SSS 


(ee 
DOG ent 
aa 
address 
a. 


QEL referencing 'DOG' 


QEL referencing CPU time 


17 18 


IBM IBM 
EDUC 10-1 EDUC 10-1 
J. K. Boggs 12/8/66 J. K. Boggs 12/8/66 


If "BONE" now issues the XCTL to "HOME," a fourth RB is created and replaces the 


Note that, for load modules, though the RB queue is built FIFO; it is the third RB. It would appear as: 


serviced LIFO. 
RB #1 RB #2 


QEL for,"DOG" 
OO ¥OF]™”VTD_M_MmNVvTv?“-ED 


RB #4 RB #1 
address address 


With this queue of RB's, we can now decide quickly which load module to 
activate. All we need to do is maintain, in the TCB-QCB, the address of the 
top RB. There: 


TCB - ASK 


Address of 


QCB to manage TASK 
Time 


QEL for "BONE" 
Se 


RB #2 
address 


A short cut method for describing this sequence in the RB que is: 


QEL for,"HOME" 
eee ee 


DOG DOG 
address QEL for 


TASK time 


To add and delete RB's, we issue in our problem program macro statements 
LINK or XCTL. The LINK macro adds another RB (RB #3) to our present chain making 
it the top RB, i.e., the program that will have the next task time. The XCTL 
macro creates an RB to replace the RB for the load module that issued the macro. 
For example, if load module "DOG" issued a LINK to "BONE" we will have a third 
RB. And the three would appear as: | 


RB #1 


RB #1 RB #2 


[SEL FoR CAPT) FOE Fog DOG 
ee NE ee ee 


Address of Address of Address of Address of RB #4 
RB #2 RB #3 RB i 
HOME 
RB #3 Ae 
—— 
| aoa 


Address of 
RB #2 


(This notation will be used in referring to RB's) 
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Notice that if "HOME" were to have a LINK to DOG, and if DOG is serially 
reusable, we can queue up this request. In fact, 0S/360 will queue in a FIFO 
queue requests for serially reusable load modules (within a JOB). We now have: 


RB #1 


Note: This QEL (request for a load module) 
portion references its QCB indirectly 
i.e., is queued (in the contents 
directory) 


0S/360 has two macros which will give the problem programmer the ability to 
create his own FIFO queues. The programmer need only define a full word as a QCB 
and allocate a double word as a QEL every time he uses the macro. Thus: 
ENQ QCB = NAME,QEL = FIRST 
DEQUE QCB = NAME,QEL = FIRST 
NAME DC_ F'O! 
FIRST DS OD 


The problem programmer can use this ability if the address of the QCB and 
QEL are known. 
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4. TASK MANAGEMENT 


The task is that control block which controls the CPU. In previous systems 
this was called multiprogramming. For instance, the 7090 and 1410 Operating 
Systems both had options which included SPOOL (Simultaneous Peripheral Operations 
On-Line). This option allowed two tasks in the system — problem program, and 
utility operations (card-to-tape, etc.). When the problem program was not using 
CPU time, the operating system switched tasks until the problem program was again 
ready to execute. Under 0S/360 there may be many tasks in the system at any given 
time. To efficiently manage these tasks, remember our old friends — the QCB and 
QEL's. The task control block is itself a QEL which looks like this: 


Addre O Vex B 


Address of Previous TCB 


Expanded QEL 
(Double Word) 


So we might consider three tasks in our queue: 


TASK A TASK B TASK C 
Address of QCB TCB-A TCB-B 


In this case, the QCB is located from the Communication Vector Table (CVT). The 
CVT is a scratch pad the system uses to communicate with itself. The QCB for task 
management looks like any other QCB: 


1 Word 
Address of 
Active QEL 


All that needs to be done to switch tasks is to change the address in the task 
QCB which is called "OLD." It turns out that we use this location to tell us one. 
of two things: (1) if an interrupt occurs and the TASK which requested the inter- 
rupt is different, and a higher priority, then the higher priority TCB address is 
placed in OLD and activated. Consider this decision table: 


"OLD" 


OLD = TCB address in Task QCB 


NEW 


TCB address requesting interrupt. 
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Give control - Consult 


to "OLD" 


Decision 
Table #1 


OLD = NEW 


OLD # NEW 


Give control 
to "NEw" 


Give control 


Decision 
Table #2 


OLD = ZERO 


Priority 
OLD > NEW 


Priority 
NEW > OLD 


When the operating system scans the TCB's, it gives control to the highest priority 
TCB which is ready. If none are ready, the system enters the WAIT state and sets 
"OLD" equal to ZERO. 


Just a brief review of what Ready means. Since the TCB controls the CPU, it 
must also reflect several states. A TCB can be in the READY, WAIT, or ACTIVE state, 


one at a time. 
ACTIVE: The task has CPU control. 


READY: The task is prepared to immediately use CPU 
/ time when it becomes available. 


WAIT: The task is waiting for an event to occur and 
cannot use CPU time until the event does occur. 


These several states have to do with the rules which activate or dispatch a task. 
These states do not affect the queueing technique. 0S/360 builds the TCB queue 

by priority. This priority is called Dispatching Priority because it is used in 
dispatching a TASK. There is also a limit Priority established for the task which 
cannot be changed by the task itself. The task may; however, change its own Dis- 
patching Priority at any time. (Dispatching Priority < Limit Priority). 
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Let's review for a moment....the queues for task and program management are: 
CVT 


System QCB "OLD" 


Highest Priority TASK 


Next TASK with QCB for Programs 


Top RB 


Next TCB 


Contents Directory 
Entry Point of Load Module 


The management of resources is based on the concept of a control QCB which is 
referenced by QEL's. The system is built this way, and the user has available a 
control program service to create queves. Now let's consider events. 


5. EVENTS 


An event is simple from the viewpoint that the event has either occurred or 
it hasn't. Considering an event as the completion of the reading of a card record 
into an input area, it either has been done or it hasn't. Thus, logically, an 
event is binary and can be considered a logical switch. In addition, when an event 
occurs, the control program must know what CPU job was concerned with the event. 
Events don't just happen, they are caused. Thus, we must know who caused it...and 
who is waiting on it. The WHO is 08/360; the requester of CPU time is a task. Thus 
an event must be associated with a task. The implementation of an event is through 
an Event Control Block (ECB). The ECB must have a bit to indicate whether the event 
has occurred and the address of the RB which requested the event. Thus, we have 
defined: 
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ECB is one full word of core. 


Low-order 3 bytes are the address of the RB 
| or the code posted upon completion of the 


event. 
Lower order byte 
Wic 
Wait Completion Bit 
Bit 


(Note that the TCB can be found by way of the back chain in the expanded QEL 
in the RB.) 


There are three types of ECB's that must be considered. First, there is an 
ECB in supervisor core that is created for every ATTACH done by the Initiator/ 
Terminator. This means that for every Job Step which is initiated in the System, 
there is an ECB in supervisor core with the I/T address. As a result, the Initi- 
ator/Terminator need only WAIT on the completion of that ECB (and my job step) 
before continuing. When the ECB is placed in the wait state, the wait bit is 
turned on, and the address of the RB which is waiting is placed in the ECB. 


The second type of event is one created by the use of the interval timer. 
The STIMER and WAIT macro can create an ECB to wait on a time event. The imple- 
mentation of this is similar to the ATTACH. 


We must have ECB's for I/O or Data. The Data Event Control Block (DECB) is 
created for the set of requests by a job step for a data set. This DECB is then 
manipulated and used by the access methods that obtain the data. 


Three types of events were discussed separately because they are separate 


logical chains which the control program services. Their use, however, is logically 


the same. 
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SUMMARY _ 


The many control blocks of 0S/360 appear at first to be confusing and 
illogical. However, two concepts are basic to their understanding and to the 
appreciation of 0S/360. 


The first concept is that of a queue. The queue is a management method 
which allows concurrent but unrelated requests to be satisfied in,vlogical order. 
Two basic control blocks are used. The QCB represents the resource and QEL's for 
requests. Flexibility in the use of queues allows a consistent and powerful tool “~ 
for developing as well as implementing 0S/360. 


The second basic concept is that of the-event. The event, or occurrence of 
an interrupt, can best be satisfied by making a note in the bits of an ECB to the 
effect that "sorsthing" is going to happen. When that "something" does happen, * 
the binary switch — ECB --- is tripped so that tasks may coordinate their activities. 


0S/360 has taken a fresh and logical approach to the multiprogramming problems 
of data processing. The present consistent approach allows many varied possibilities 
for compatible growth. The concepts of queues and events will become as basic as the 
Hollerith Card Code. 
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APPENDIX A 


‘QUEUE UTILITIES 


perform service functions in the manipulation of 


QEL's in a FIFO manner. 
QEL's in a LIFO manner. 


QEL's in a PRIORITY manner. 


i (1) Adding simple 
(2) Adding simple 
° (3) Adding simple 
(4) DELETING the TOP QEL. 
| (5) DELETING a specific QEL. 
t 
4 
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so 


se ot oe 


% tt 


PCN ENTRY 
REL FR 4 = QEL ADDRESS 
os REGISTE2 5 = OCB ADDRESS ss 
FR 14 = RETURN ADDRESS 


THIS ROUTINE USES REGISTERS 657 AND &, 


_.—.—_ KE GISTER 6 = Wi pa Sa te ae See es eh 
REGISTER 7 = WORK AND RETURN ENDGECATAR 
REGISTER 8 = BASE REGISTER 
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jt eH a ee ee ee ee ee 


* te at | dt a te we 


reer! 0 ol Oe Sa Es 


REG T= 48 


REG T= 192— 


FRROR CONDTT-LONS AND INDICATIONS . 


D2: _JNCLEAP.CHECK 
BITS 3-7 OF BYTE ADDRESSED BY RES 4 ALL 
oo eae REGISTERS LEFT UNCHANGED. 


£02. ALL. 
REGISTERS LEFT UNCHANGED. 


_ ATTEMPT MADE T9 O8f71P_ A_QFL WHICH IS NOT 
CHAINED IN THE QUEUF. ALL 2EGISTERS 
_ CO EET UNCHANGED, 


PREVIOUSLY BUSY RFSQURCE HAS NOW BECOME 


lw) 6.) I NACTIVE DUE LTO THE DTLETION OF A OFL. 
(THES INDICATOR 1S NOT ON BY LTTSFLF. 


_REG_7= 15 ___.- PREVIOUSLY INACTIVE. RESOURCE HAS JUST 


BECOME ACTIVE BUF TI SUCESSFUL ARNITION 
_..... OF A QEL._CTHIS INDICATOR FS NOT CN 
BY ITSELF.) 


PEG 7= 32 __...JNDICATES THE SUCESSFUL ADDITIGN UF 4 QL. 


-  §FE REG 7216 AND REG 7= 37. 


RES T= 56  ___sNDECATES THE SUCESSFUL DELETION OF 4A QEL. 


REG T= 7? SEE REG 7= 8 AND REG T= 64. 


REG T= 128 .. INDICATES A PREVIOUSLY ACTIVE QFL HAS 


BEEN MADE ACTIVE. 


SEE REG 7= 64 AND RFG T= 128 . 
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ATTEMPT MADE TO NANPA QEL EROM AN INACTIVE 


GALQ 247 
USING *38 
LA ee 


SEY RFS 7=" TO INOTCATE JMVALTA 
‘ag ? 


* rial eS Ss eee ee 2, a. as é Le. xe 
TM SC4),RENINNING: TEST FO2 ANMING FTF. 
BC 1,ADDF IFO oe - BRANCH IF YES. 
TM “(4),B999NNFOLT 08 TEST FOR ANCING LIF. 
RC 1,ADD0L IFO . BRANCH IF YES. 
™ 4) ,RENANONLADS TEST FOR ADGEING PRIM. 

wo. BOW. 1L.ADDPS C HVESe scx: 

™ 414) ,6899099199N0 TEST FOR DELETING TP OFL. 
RC 1sDELTOP. . BRANCH IF YES. 
™ R(4),REINATNNNAOS TEST FOR DELETING SPFCTFIC Fl. 
BC Y,NDELSPEC _ . BRANCH IF YES. 
BCR 15,14 


ACOFTED T™™ 


_LT& . 696 
BC 7,FIFG 
IC 6, 7(5) 
* 
ete 45 
STC 4, 1(5) 
LAST _. gr He A cyosee 
ST hy (4) 
LA 1432 - 


AO5),B8L 7990008 ~~) oO TEST TF ace TS BUSY. 
BC  AygtlASTAN 


w+ BRANCH TF.NOT BUSY. 
REG S= ADDFESS NEXT AED OTN CHATN, 


BRANCH TF NOT LAST OFL IN CHATN. 
ee .. SAVE FIRST RYTE FRO® LAST GEL IN 
CHAIN. : 


DORESS INTO LAST QEL. 


STORE SAVFD AVYTF. | 
oo GET A FULL WuRD OF ZERO. 
CLEAR NEW QOEL TU ZFERN, 


_...._ SET REG 72 32 TO INDICATE aA SUCESSFUL 


ADDITION OF A DEL. 


sa a ac eg a Sa 
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bata 


 a05)_BELONNNOADS 


OFLSPFC TT TEST TA SEF IF OC8 TS ®usy. 


. BC 8,NOTBUSY ss BRANCH IF NCT BUSY. 
L fy (5) GET FIRST QFL ADDRESS. 
——— LA... fed fh) CLEAR HIGH ORDER BYTE. 
CR 5y4 TEST TO SFF ITF DFLFETING FIRST OFL. 


BC ..8,TOPONE ss BRANCH IF YES, 


LR 795 inde QOC8 ADDRESS. 
SAC IR eit ae, ie Se ree 
L 69%(5) “GET. NEXT QFL ANDRESS. 


CR 4494 SFE TF FOUND 
BC eo PLT E OUR et ee 
L 59916) 

(itn mens oteedis ce erg NEE Pe. su reo cee Be a ee ok a 
LTR 595 


“Sayeed Se Fg RO a et ee ly 


NOTFOUND LR 597 RESTORE ORIGINAL VALUE OF REGS, 
LA  Te4... ..._-___-SET¥ REG 724 TO INDICATE ATTEMPT. 
% TO OFLETE A QFL NOT IN THE QUEUF. 
BORE ool ee oe Lees she tee 
BC 15514 RETURN TO CALLE? 


ee LINK ADDRESS INTO 


PRECEEDING QEL. 
wl. 27264 2. Le... SET_REG .7=..64.T0 INDICATE A 


x SUCESSFUL DELETION 
BG a he oso Ne bee ae 
BC 15414 
wit ne ND ED i ee 
ANDLTFOQ T™ SEHD, BF TONADNIOS TEST IF NCR 1S BUSY. . 


BC... B,LASTAD .._.. _..__ BRANSH ITF NUT BUSY. 
Ab de L 6905) 
2 NL4 TO NEW OEL. 


LA 4,704) CLEAR HIGH CROER BYTE. . 
ST 49906). STORE NE OFL ADDRESS INTO QC. 
ol AC 5 9 xt8or TURN ON BUSY BIT OF OCH. 
wee LA 2 D2 3207) -.._SET. REG T= 32. TO. INDICATE A SUCESSFUL 
* ADDITION OF A QEIL. 
aN a 
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ASYQDRY.} TM 


3C ByLASTAD BRANCH [F NUT SUSY. 

1 fy (5) GET NEXT JEL ADDRESS IN CHAIN» 

CLO. 41s ee 

uC PeHlsG BRANCH TF NEW QFL IS HIGHER PRIORITY. 

Le 596 REG S= PREVIOUS OFL ADDRESS. 

L 7, (6) 

LA Te T) 

LTFe Ty, 7 

BO. Pe PRID UU BRANCH SE NOT LAST OEL IN CHAIN. | 

HTH IC 7975) — SAVE FIRST BYTE FROM HIGHER P2TRRTTY 
* PREVIOUS QFL,. 

ST 49 (5) STORE NEW OEL ADRESS INTO PREVIOUS QEL. 

STC Ty (5) STORE SAVED BYTF. 

RC Ast AST BRANCH ITF PRFEVITUS SFL WAS LAST ON CHAIN. 

— AC. 72°14)... FF SAVE FIRST SYTE FROM NEW QEL. | 

. ST 6 >(4) STORE ADDRESS GE LOWER PRIMOTTY OFL 
* = . _ ANTO NEW QEL. 

STC Te M4) STORE SAVED BYTF. 

LA 7,3? SET REG T= 32 TH INDICATE A SUCESSFUL 
z ADDITION OF A JEL. 

ee ef CR Ba) eae ee ei ay een eee N acuetce . aitlet deat 

LASTAD LA 7914 . INDICATF RESHURCFE HAS GUST &ECIME 
* BUSY. 
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PESD,BELNMANANNG ~~ 6OTEST TE OCR IS RUSY. 


15, A032 


NELTIP ™ 


25) ,BE2ONANANNE 


BC BR »NOTSUSY 
L 49° (5) 
TOPONE_t. 7, 084) 
LA Te, *CT7) 
LTR Tel a sites: 
4C¢ ®,f QUAL 
L 0914) 2 LL. 
L 7,%(6) 


ee “ti epemmetey Sa UL) [rere ee eee eae 
(57,8  10OINANANE 


T™ 
* - BEEN ACTIVATED. LE IT ‘AD, THEN BITS 
2-7 MAY SE SIGNIFICANT. 
RC (1a WASBUSY BRANCH IF YES. 
LA Tyh% SET RES 7264 Thi INDICATE “A SUCESSFUL 
* actos tits gates ce ee, DELETION OF A OFL, 
aa | YEO), BY LIDIINAINNG TURN JN BUSY BIT. 
BCR 15,14 .  _.. as 
WASAHSY LA 7,192 SET 28°F 7=644178 JT.) PROTCATE A 
* SUCESSFUL DELETION AND THAT THE 
« NEWLY ACTIVATED? QEL HAS SP FEVIAUSLY 
* seme, buted eee 9 Boe, _-.._ BEEN ACTIVE, 
ACEv 315,14 
YoOT@USY LA 7,2 SET REG 7=2 TO INDICATE ATTEMPT 
* MANE TON DROP A QFE FRUM AN 
tt | -LNACTIVE 2ESOURCE. 
AC 15,SU8 60 CLEAR OCR TO ZFS. 
EQUAL... LA 7,72. __.....SET_ REG 7=72_TU0 INDICATE THAT A 
* PRFYEONUSLY SUSY RFSQUECE FAS 
* NOw BECOME INACTIVE. 
SUS se HS ORTATN A WORD AF ZJE2, 
ST Bs°(5) CLEAR QC8 TO ZERO. 
gC? 15,14 
ee: | ERO SU Ly oe eee RETURN. Tu CALLER. 
* CUNSTANTS 
CSN ac xeaaqnnane CON= THIEF 7ERM SYTES. 
REG GQ pc x8 738 _ TO BE USED FOR NONSPECIFIC DELETE. 


TEST TF 9CP TS BUSY. 
BRANCH [F NUT BUSY. 
GET TOP QEL ADORESS. 


BRANCH [TF NELETING LAST GEL IN CHaALN 
GET NEXT EL ADDRESS. 


MOVE CONTENTS OF OFL INTL! OCB. 


eae. meme = ee 


TEST T Seb TF OEL HA AT ONE TIM 


33 


